Skip to content

Comments

feat(mtda-cli): find all mtda agents in give ip pattern#565

Open
shikl3x7 wants to merge 1 commit intosiemens:nextfrom
shikl3x7:find_mtda_devices
Open

feat(mtda-cli): find all mtda agents in give ip pattern#565
shikl3x7 wants to merge 1 commit intosiemens:nextfrom
shikl3x7:find_mtda_devices

Conversation

@shikl3x7
Copy link

This commit is just proposal to start discussions on having an Api to search all agents and their status, which would potentially help in automation labs with multiple setups to get the status of agent and use it to deploy.
For now, I have used the storage_status, if the idea seems valid and fit, would like work and add required Apis in main to make this feature more dependable.

This commit is just proposal to start discussions on having
a api to search all agents and their status, which would
potentially help in automation labs with multiple setups
to get the status of agent and use it to deploy.
For now i have used the storage_status if the idea seems valid
and fit ,would like work and add required apis in main to make this
feature more dependable.

Signed-off-by: Shivaschandra KL <shivaschandra.k-l@siemens.com>
@github-actions github-actions bot requested a review from chombourger January 22, 2026 12:16
@fmoessbauer
Copy link
Member

Hi, IMHO this should not be an mtda feature, but instead rely on lava, Netbox or a custom fronted implementation. MTDA can assist by sending mdns broadcasts to make other participants aware of its address / existence.

I used MTDA interactively in a larger lab by putting an Nginx as reverse proxy in front of the nodes. The Nginx can also be exposed without providing direct access to the testlab. Example configuration for that was added by me in 1e383d5. With #563 the UI is also almost feature complete, despite it is still tricky to use non interactively as the websocket interfaces are not documented (are not public interfaces).

In general, running MTDA in a bigger lab is still tricky due to #562 and #524. Once these are solved, we could even think of a MTDA proxy as dedicated application that just relies data to the correct (and discovered) MTDA device. But this should be a standalone application which is not part of MTDA itself (the same applies to the client as its source code is tightly coupled with the server).

@chombourger
Copy link
Collaborator

a while back, support for ZeroConf was added. see

# Initialize ZeroConf

the feature may need to be documented & tested.

@shikl3x7
Copy link
Author

shikl3x7 commented Feb 3, 2026

a while back, support for ZeroConf was added. see

# Initialize ZeroConf

the feature may need to be documented & tested.

Shall I change the implementation to use the ZeroConf and propose or shall we use this as part of the of our automation framework and just document here the usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants